Methods and systems for automated generation of bills

ABSTRACT

The present invention provides methods and systems for processing bills electronically. Generally, a bill is created for a customer using billing information and master data from a biller and master data from a customer. Billing information is received from the biller by a first processing module having access to the master data of the biller. The first processing module generates a bill using the billing information and the master data of the biller. A second processing module having access to the master data of the customer provides customer data to the first processing module. The bill is transformed into a format specified in the master data of the customer by the first processing module if the format of the generated bill is not the format specified in the master data of the customer. The generated or transformed bill is transferred to the second processing module by the first processing module.

RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional PatentApplication No. 60/406,986, which was filed Aug. 30, 2002, which isincorporated herein by reference.

DESCRIPTION OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The technical field of this invention is electronic dataprocessing. More particularly, the invention relates to methods,computer programs, computer program products, and systems for automatedbilling systems and, still more particularly, for processing, generatingand presenting an electronic invoice to a customer for remote review andpayment.

[0004] 2. Description of the Related Art

[0005] It should be understood that the term “presentment” as usedherein does not include the specialized definition normally associatedwith commercial paper, i.e. the production on a negotiable instrument toa drawee. Rather, the term refers to providing via electronic meansinformation, particularly an “invoice,” containing at least the samecustomer billing data typically included on a paper invoice. Thiselectronic presentment may preferably, but not exclusively, take placethrough the use of an internet- or intranet website or via email or SMS,such as, for example, by making a web site accessible to one or morepersons. It may further take place by sending computer-readable storagemedia, like disks, ZIP disks, NW magneto-optical disks, CD-, CDRW-, DVDROMs or other similar materials via

[0006] There exist many known methods and systems for electronic billpresentment and payment (EBPP) in enterprise resource planning (ERP)software environments. For example, U.S. Pat. No. 6,044,362 discloses asystem for automated electronic invoicing and payment for providingremote customer review of automated billing from an invoicer. The systemincludes invoice presentment electronics having a control system andfirst communication electronics. The system also includes at least oneremote authorization terminal having a customer interface, the terminalhaving second communication electronics adapted to operativelycommunicate with the first communication electronics. The control systemof the invoice presentment electronics is adapted to provide billingdata, regarding a customer invoice preauthorized for automated billing,to the first communication electronics for transmission to the secondcommunication electronics. The customer interface of the remoteauthorization terminal is adapted to present the billing data to acustomer and to receive a response relating to the billing data from thecustomer, the response indicating one of acceptance of the billing datafor automated billing or modification of the billing data for modifyingautomated billing. Acceptance can either be an active response from thecustomer or a passive response such as, for example, automaticacceptance up to a preset limit.

[0007] U.S. Pat. No. 5,465,206 discloses a bill pay system whereinparticipating customers pay bills to participating billers through apayment network operating according to preset rules. The participatingcustomers receive bills from participating billers of (paper/mail bills,e-mail notices, implied bills for automatic debts) which indicate anamount, and a unique biller identification number. To authorize aremittance, a customer transmits to its bank (a participating bank) abill pay order indicating a payment date, a payment amount, thecustomer's account number with the biller, a source for the funds, andthe biller's biller identification number, either directly or byreference to static data containing those data elements. The bank thensubmits a payment message to a payment network, and the payment network,which assigns the biller reference numbers, forwards the payment messageto the biller's bank. For settlement, the customer's bank debits thecustomer's account and is obligated to a net position with the paymentnetwork; likewise, the biller's bank receives a net position from thepayment network and credits the biller's bank account. If the customer'sbank agrees to send non-reversible payment messages, the customer's bankdoes not submit the transaction until funds are good unless thecustomer's bank is willing to take the risk of loss if funds are notgood, such as in the case of a guaranteed payment network. The biller'sbank, upon receipt of the payment message, releases the funds to thebiller, and provides A/R data to biller in a form which the biller hasindicated, the form being one which does not have to be treated as anexception item to the biller. The biller's bank is assured of payment bythe payment network, unless the transaction is a reversible transactionaccording to the preset rules of the payment network. In specificembodiments, the customer initiates the bill pay orders manually, viapaper at an ATM, via PC, or via telephone keypad.

[0008] Another system is known from the website www://ofx.net. OpenFinancial Exchange (ofx) is a broad-based framework for exchangingfinancial data and instructions between customers and their financialinstitutions. It allows institutions to connect directly to theircustomers without requiring an intermediary. Open Financial Exchange isan open specification that anyone can implement: any financialinstitution, transaction processor, software developer, or other party.It uses widely accepted open standards for data formatting (such asXML), connectivity (such as TCP/IP and HTTP), and security (such asSSL). Open Financial Exchange defines the request and response messagesused by each financial service as well as the common framework andinfrastructure to support the communication of those messages. The dataof biller and customer are held in the same system.

[0009] In systems that use a direct contact between biller and customer,however, it is difficult to technically implement a business scenario inwhich bills of different billers are presented to one customer. Further,it is difficult to integrate and maintain such systems in the IT(information technology) systems of billers and customers, particularlyif a high bill volume has to be handled.

[0010] Thus, there is a need for a method, software application, and/ordata processing system that provide a more efficient solution to some orall of the problems described above, that is, methods and systems formore efficient bill processing.

SUMMARY OF THE INVENTION

[0011] In accordance with the present invention, as embodied and broadlydescribed herein, methods and systems consistent with the principles ofthe invention provide a method for processing bills electronically,wherein a bill is created for a customer using billing information andmaster data from a biller and master data from a customer. Billinginformation is received from the biller by a first processing modulehaving access to the master data of the biller. A bill is generated bythe first processing module using the billing information and the masterdata of the biller. A second processing module having access to themaster data of the customer is requested to provide customer data to thefirst processing module. The bill is transformed into a format specifiedin the master data of the customer by the first processing module if theformat of the generated bill is not the format specified in the masterdata of the customer. The generated or transformed bill is transferredto the second processing module by the first processing module.

[0012] Another aspect of the invention is to provide a computer systemfor processing bills electronically, wherein a bill is created for acustomer using billing information and master data from a biller andmaster data from a customer. A computer system consistent with thepresent invention comprises a memory having program instructions, aninput means for receiving and entering data, an output means for sendingand presenting data, a storage means for storing data, and a processorresponsive to the program instructions. The processor receives thebilling information from the biller by a first processing module havingaccess to the master data of the biller and generates a bill by thefirst processing module using the billing information and the masterdata of the biller. The processor also requests data of the customerfrom a second processing module having access to the master data of thecustomer by the first processing module and transforms the bill into aformat specified in the master data of the customer by the firstprocessing module if the format of the generated bill is not the formatspecified in the master data of the customer. The processor alsotransfers the generated or transformed bill to the second processingmodule by the first processing module.

[0013] Methods and systems consistent with the present invention providesolutions for providing a large amount of bills in an efficient way to aspecific customer. A plurality of billers can provide their billinginformation to the first module. The billing information is transformedinto a bill in a format specified by the respective customer.

[0014] The present invention is further directed to a computer system, acomputer program, a computer-readable medium and a carrier signal, eachcomprising program code or instructions for processing bills accordingto the inventive method and in its embodiments.

[0015] Each of the processing modules may be installed as computerprograms on different hardware systems (computers or computer systems),and run separately and independently of each other. The differentsystems may be connected in the form of a network to communicate witheach other. In addition, one or more of the processing modules may be apart of (integrated in) another processing module.

[0016] Additional objects and advantages of the invention and itsembodiments will be set forth in part in the description, or may belearned by practice. It is understood that both the foregoing generaldescription and the following detailed description are exemplary andexplanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in andconstitute a part of this specification, illustrate embodiments of theinvention and, together with the description, explain the principles ofthe invention. In the drawings,

[0018]FIG. 1 is a schematic block diagram of one exemplaryimplementation of the inventive method within a computer system,

[0019]FIG. 2 is an block diagram of one exemplary implementation of theinventive method,

[0020]FIG. 3 shows an overview of an example of an inventive electronicbill presentment and paying system consistent with the presentinvention,

[0021]FIG. 4 is a block diagram of one exemplary interconnection of afirst and second processing module,

[0022]FIG. 5 is a flow diagram of one exemplary inventive billingprocess consistent with the present invention,

[0023]FIG. 6 is a flow diagram of an exemplary inventive billpresentment process consistent with the present invention,

[0024]FIG. 7 is a flow diagram of an exemplary process for registering acustomer for an inventive electronic billing process consistent with thepresent invention,

[0025]FIG. 8 is a flow diagram of an exemplary process for activating aregistering of a customer by a biller consistent with the presentinvention,

[0026]FIG. 9 is a block diagram of an exemplary table for mapping theIDs of a biller for a customer to the IDs of a customer for a biller,

[0027]FIG. 10 is a block diagram showing integration of e-banking intoan electronic bill presentment and paying system consistent with thepresent invention,

[0028]FIG. 11 is a flow diagram of an exemplary process for initiatingand performing a bill review by a customer consistent with the presentinvention,

[0029]FIG. 12 is the continuation of the flow diagram in FIG. 11, and

[0030]FIG. 13 is a block diagram of an exemplary archiving process fordata of billers or customers.

DETAILED DESCRIPTION

[0031] Computer systems and the programs that control them are closelyrelated. As used herein, phrases such as “the computer provides,” “theprogram provides or performs specific actions”, and “a user performs aspecific action” are used to describe actions by a computer system thatare controlled by a program or to indicate that the program or programmodule is designed to enable the computer system to perform the specificaction or to enable a user to perform the specific action by a computersystem. A computer system can be a stand-alone computer, such as a PC ora laptop, or a series of computers connected as a network, such as anetwork within a company or a series of computers connected via theinternet.

[0032] Processors suitable for execution of a computer programconsistent with the present invention include, by way of example, bothgeneral and special-purpose microprocessors, and any one or moreprocessors of any kind of digital computer. Generally, a processor willreceive instructions and data from a read-only memory or a random accessmemory or both. Generally, a computer comprises a processor forexecuting instructions and one or more memory devices for storinginstructions and data. Generally, a computer will also include, or beoperatively coupled to receive data from or transfer data to, or both,one or more mass storage devices (storage means) for storing data, e.g.,magnetic, magneto-optical disks, or optical disks. Information carrierssuitable for embodying computer program instructions and data includeall forms of non-volatile memory, including by way of examplesemiconductor memory devices, such as EPROM, EEPROM, and flash memorydevices; magnetic disks such as internal hard disks and removable disks;

[0033] magneto-optical disks; and CD-ROM and DVD-ROM disks. Theprocessor and the memory can be supplemented by, or incorporated in,ASICs (application-specific integrated circuits).

[0034] To provide for interaction with a user, the present invention canbe implemented on a computer having a display device such as a CRT(cathode ray tube) or LCD (liquid crystal display) monitor fordisplaying information to the user and a keyboard and a pointing device,such as a mouse or a trackball, by which the user can provide input tothe computer. Other kinds of devices can be used to provide forinteraction with a user as well. For example, feedback may be providedto the user in the form of sensory feedback, such as visual feedback,auditory feedback, or haptic feedback; and input from the user can bereceived in any form, including acoustic, speech, or haptic input.

[0035] Reference will now be made in detail to the principles of theinvention by explaining the invention as a data processing process,examples of which are illustrated in the accompanying drawings. Theexamples mentioned herein are intended to explain the invention and notto limit the invention in any kind.

[0036] The first processing module is hereinafter referred to as “billerservice provider” (BSP), the second as “consolidator,” and the third asthe “customer service provider” (CSP). If the CSP is integrated in theconsolidator, the resulting combination is referred to as “integratedCSP” (iCSP).

[0037]FIG. 1 depicts one exemplary implementation of an embodiment ofthe invention, that is, a computer system with program modules forperforming the inventive method. FIG. 1 shows a computer system 101comprising a computer 103 having a CPU 105, a working storage 112(memory), in which software applications are stored for processing byCPU 105. The software applications comprise program modules 106, 109,110 for carrying out the first, second and third processing modules,respectively, according to the inventive method.

[0038] Computer system 101 may further comprise input means 117, outputmeans 112 for interaction with a user, such as for starting the programmodules and/or for data input, and general input/output means 104,including a net connection 114, for sending and receiving data, such asdata on billing information, bills, payment orders, customer and billermaster data. A plurality of computer systems 101 can be connected vianet connection 114 in the form of a network 113. In such a case, each ofthe modules 106,109,110 may be installed and run separately and/orindependently on the respective network computers 113. In this case, thenetwork computers 113 can be used as further input/output means,including as storage locations. Computer system 103 may further comprisea first storage means 107, in which master data of the customer may bestored, and a second storage means 108, in which the master data of thebiller may be stored.

[0039] In at least one embodiment of the present invention, firstprocessing module 110 (BSP) has access to the master data of the billerstored on storage means 108, and the second processing module 106(consolidator) has access to the master data of the customer stored onthe storage means 107. A biller 111 and a customer 115 may be connected,permanently or on an as-needed basis, to computer system 103 viainput/output means 104. A further connection may be established to apayment service 116. The interactions of biller 111 and customer 115with the accompanying program modules 110,109, respectively, areindicated by dashed arrows as is the affiliation of the BSP and theconsolidator to the respective storage means 108, 107.

[0040]FIG. 2 illustrates one example of a network connection of severalprogram modules of BSPs 201 a, 201 b, consolidators 202 a, 202 b, 202 c,and a CSP 203, each of which is installed on a separate computer system204 a,b, 205 a,b,c and 208. The respective computer systems may beidentical or different from each other, depending on the requirements ofthe application case. The computer systems may be located in differentcountries in the world. One or more billers can have access to thatnetwork via computer systems 206 a,b by, for example, using web browsers207 a,b. These computer systems 206 a,b may be connected to each of theBSPs 204 a,b. A customer can have access to the network via a computersystem 210 having a web browser 211. For performing the paymentsassociated with the bills, an computer system 209 of a payment serviceprovider having an e-banking application may be connected to one or moreof the consolidator systems 205 a,b,c.

[0041] According to the inventive concept of separating the billermaster data from the customer master data, as many BSPs as necessary canbe connected to one consolidator. This avoids superfluous movement ofdata, because the customer master data need not be shifted or copied tothe module which processes the bills, as would be necessary using mostprior art methods. With this concept, billing volumes of over severalmillion bills per month can be handled by using several BSPs connectedto one consolidator, for example. If customer master data needs to beupdated, only the data base of the consolidator needs to be changed insystems consistent with the present invention. The BSP data base is notaffected by such an update. A further effect is that, in most if not allapplications, maintenance costs for the master data are reduced.

[0042]FIG. 3 provides an overview of possible formats and interfaces forthe data exchange between a biller and the BSP, the BSP and theconsolidator, the consolidator and the CSP, and between the CSP and acustomer (payer). As shown in FIG. 3, the biller side may be split intothree cases: Large billers using an SAP ERP system (such as one providedby SAP AG, D-69190 Walldorf, Germany), large billers using a non-SAP ERPsystem, and small billers. In this example, the terms “large” and“small” refer to the turnover of the respective company or person and ismeant to be exemplary. The same cases may be found on the customer side.In FIG. 3, the CSP is shown in the example for large payers integratedin the consolidator as iCSP and for the small payers it is a separateprogram module with two alternative implementations, SAP Portals CSP andOnline Banking CSP.

[0043] In this example, the BSP supports four formats for the billinginformation: the IDOC, FLATFILE, EDIFACT, and a predefinable BSP formaton which the systems of the biller and the BSP have to be adapted duringthe installation of the respective software. The systems in the billerside may communicate with the BSP using, for example, HTML, HTTPS,XML-IDOC (SSL), FLAT (SSL), EDI (SSL). The BSP and the consolidator maycommunicate via XML, as well as consolidator and CSP. The CSP and/oriCSP may communicate with the systems of the customer using, forexample, HTML (HTTPS), XML-IDOC (SSL), EDI (SSL) and XML.

[0044]FIG. 4 shows an example of possible interfaces (IF) with which theBSP and/or CSP and/or iCSP may be provided: a biller or customerEDI/file IF, Web GUI (graphical user interface), BCX, Flat FileConversion, Print IF, Archiving IF, a Cost Event IF for connection witha billing engine, an IF for connection with a payment service (financialinstitution) or a CCX IF for connection with an internet serviceprovider (ISP). In order to view its list of bill summaries, the billercan connect to the BSP. The customer can connect directly to theCSP/iCSP or indirectly via a connection to financial institutions orISPs. For itemized bills and registration, the customers may connect tothe BSP.

[0045] The BSP may store all data associated with the biller in apartner data base. The partner data base may include, for example,master data of the billers comprising addresses, identification keys,authorizations, biller's integration level (interfacing capabilities andimplemented processes), logos, location of the logos on the bill,advertisement forms for personalized promotions, formats for credits,digital signatures, etc. The billing information, the generated and/ortransformed bills, and bill details for web presentment may be stored,for example, by the BSP in a business object data base. A businessobject in this sense may comprise all data belonging to a businesstransaction that is the cause for the specific bill. Typical billinginformation comprises, for example, the article, type of article,article number, number of the articles, position, ID, description ofarticle, price, tax information, addresses (such as for delivery),references (URLs for details), dates (such as billing, shipping, orreceipt date) etc.

[0046] The consolidator/iCSP may store all data associated with thecustomer and the financial institutions in a partner data base. Forexample, the partner data base may comprise master data of the customerincluding the customer's address, addresses for communication within thecustomer's organization and between the customer and the biller, aformat in which the bill shall be presented, addresses for providingstatus information, dispute results, or review management,identification keys, authorizations, digital signatures, etc.Consolidated or aggregated bills or bill summaries to be presented tothe customer may be stored by the consolidator/iCSP in a consolidator'sbusiness object data base. As many BSPs as necessary to handle the billvolume may be connected to a consolidator/iCSP in such a way.

[0047] In at least one exemplary embodiment, program modules 106, 109,110 are processed by CPU 105 in FIG. 1 in order to carry out theinventive method. In this example, steps as described in the followingsection may be performed by the computer system 101 or the systems ofthe network as described above.

[0048]FIG. 5 shows a flow diagram of an exemplary implementation of aninventive process. The time axis in FIG. 5 runs from top to bottom. Asshown in FIG. 5, a biller may send billing information to the BSP (step505). The biller may send such information using an ERP computer system.The biller may also send the billing information in a format agreed uponwhen the biller registered with the BSP. The BSP may create a bill andassign a status of “new” to that object (step 510). The new bill may becreated based on the received billing information, the biller's masterdata, or a combination thereof. The new bill may be in paper orelectronic form. The BSP may then send a request for information aboutthe customer (CustomerInfoRequest) to the Consolidator/iCSP (step 515).The consolidator/iCSP may respond to that request and return to the BSPavailable data from the customer master data base for the inquiredcustomer (CustomerInfoResponse) (step 520). In addition to theinformation given above, the response may contain other information,such as whether a customer requests billing data for web presentment(so-called “thin” consolidation because only the main information ispresented to the customer), for processing in an ERP system (also called“thick” consolidation because the bill sent electronically to thecustomer includes bill details), in a digitally-signed format accordingto applicable tax or other legal regulations, or in an encrypted format.In at least one embodiment, the response may contain information on thebiller-to-customer relationship (BCR) regarding their respective IDs intheir respective ERP systems. In at least one embodiment, the responsemay contain authentication information for accessing itemized bills orfor encryption (such as a list of digital IDs, distinguished names,certificate serial numbers, or other information referencing X.509certificates).

[0049] The BSP may then transform the bill into the format received withthe CustomerInfoResponse. In certain embodiments, it is recommended thatdata be converted from the source to the destination format as close tothe source as possible. If possible, conversions should be avoided, asconversions generally increase the risk of data loss. In certainembodiments, a BSP may use external conversion services. A BSP may useexternal conversion services if, for example, a destination format cannot be produced internally or if using external conversion services isotherwise advantageous. For example, a BSP may choose to use externalconversion services if doing so allows the BSP to digitally sign thebills in a manner conforming to government regulations for VATdeductions. The customer may directly process and archive the invoice inone simple integrated process. In certain embodiments, the presentinvention may allow application content to be preserved easier. Inaddition, if the total number of supported formats is small, the amountof transformation work and costs may be reduced. Adaptations toaccommodate differences between the specific formats required by eachPayment Service Providers (PSP) can be handled in the consolidator/iCSP.

[0050] In conventional EBPP systems, conversion is often done indirectlyusing an intermediate (“in-house”) format. Source data is firstconverted into the in house format and then converted into thedestination format. Using this technique, the number of conversions islinear (2 n) with respect to the number of formats (n), compared ton(n−1) conversions in the case of direct conversions. However, eventhough an intermediate format can also be used in the conversion on thepresent BSP, the conversion to the customer format should happen asearly as possible in the presentment process.

[0051] By converting the invoice to the end user format at the BSP, thebill can be signed at the BSP. If the payment formats are converted toBiller and Customer formats on the consolidator, only the consolidatorwill need knowledge of the various payment formats required by each PSP.The BSP and CSP may remain independent of payment formats.

[0052] If implemented on a hardware system of a third party, the BSP maybe considered an outsourcing partner of the biller, which may beadvantageous in certain situations. Similarly, implementing the CSPand/or the consolidator/iCSP on third party hardware may also beadvantageous in certain situations. In certain embodiments, for example,the BSP may produce the bills (electronic and/or paper) on behalf of thebiller. If necessary, the biller as a legal entity may need to assignthe right to digitally sign bills to the legal entity that operates theBSP. The BSP may then be responsible for producing a digitally-signedinvoice message in a format accepted, readable, and processable by thecustomer and valid for VAT deduction. This is achieved by, for example,using the conversion process described above.

[0053] In certain embodiments, the customer may check to see that theBSP has the authority for issuing invoices on behalf of the biller. Forexample, a list of billers (see Customer Registration for E-Bills) maybe posted on the Internet with hyperlinks to one or more documents thatindicate that the BSP has the necessary authority. For added security,the documents may be digitally signed by the biller.

[0054] In many European countries, until recently, customers has topresent to authorities a paper invoice in order to obtain a refund ofVAT (Value Added Tax) for purchased goods. The invoice document had tobe printed by the biller and contain certain required information. Otherforms of invoices, such as electronically transferred bills printed bythe customer, were not accepted. In the European Union and othercountries (such as Switzerland), new laws and regulations allow VATdeduction on electronically transmitted bills, if they are digitallysigned by the biller. The certificate and the procedure used for signingare regulated.

[0055] In order to generate an invoice in the requested format, the BSPmay have access to external conversion services such as, for example, aweb service. In this case, the bill to be presented to the customer maybe prepared by the external conversion services. If the customer cannotbe reached electronically, that is, for example, if theCustomerInfoResponse returns “unknown”, the BSP can generate a paperbill and/or inform the biller accordingly.

[0056] Each invoice may be associated with an invoice delivery date,that is, a date when the invoice should be transmitted to the customer.When an invoice delivery date is reached, the BSP delivers thetransformed bill to the consolidator/iCSP (InvoiceDeliveryRequest) (step525). Alternatively, if no invoice delivery date is associated with theinvoice, the BSP may deliver the transformed bill to theconsolidator/iCSP immediately or at periodically scheduled times.Additionally, the BSP may submit to the consolidator/iCSP information onthe integration status of the biller (for example, BillerPreferences,I-Summary, I-Details). This information may be used by theconsolidator/iCSP to perform operations on the received transformedbill. For example, the consolidator/iCSP may use such information whenprocessing a request for credit, determining the status of a bill (suchas, for example, if a bill has been delivered or paid), or in processingother types of inquiries related to the billing process such as disputeresolution. The consolidator/iCSP may indicate to the BSP that atransformed bill is available for access by the customer (by, forexample, sending an InvoiceDeliveryResponse) (step 530). The BSP maythen change the status of the bill to indicate that it is ready to bedelivered (step 535). The consolidator/iCSP may then change the statusof the received transformed bill to indicate that it is ready to beopened (step 540).

[0057] At this point, the next steps in the process may depend oncertain factors such as whether the customer is a web customer or an ERPcustomer, whether payment preferences are applicable to the specificcustomer, or on the connection status of the biller's and customer'sPSP. In certain embodiments, web presentment and payment may be handledusing a banking portal (CCX IF), an Internet Service Provider (ISP) anda PSP, an ERP connection and payment using a payment channel, or an ERPconnection and payment using an SAP EBPP system.

[0058] In step 545, the bill is “delivered” to the customer. “Delivery”may involve the consolidator/iCSP transmitting the bill to the customeror the customer retrieving the bill. For example, in certainembodiments, the customer may access the transformed bill via a webportal on the consolidator/iCSP data base. In certain embodiments, theprocess may involve additional optional steps such as verifying theinvoice, crosschecking the information in the invoice with materialsmanagement information, or checking with payment processing systems.

[0059] In step 550, a payment order is sent to the consolidator/iCSP. Incertain embodiments, the payment order may be digitally signed by thecustomer or other vouching entity. The consolidator/iCSP may then passpayment scheduling information to the BSP (SetEBPPStatusRequest) (step555), which with BSP may use to schedule the payment (step 560). Incertain embodiments, the BSP may mark the payment for immediate payment.The BSP may optionally inform the biller about the scheduled payment(step 562). Immediately or at a requested payment date, theconsolidator/iCSP generates a payment order in a format required by thePSP and sends the payment order to the PSP (step 565). The payment ordermay be cryptographically authenticated. The PSP processes the payment,either a debit (570) or a credit (575) and may use interbank paymentprocessing to do so, if required or desired. The consolidator/iCSP mayoptionally send a debit notice to the customer (step 580). Theconsolidator/iCSP may generate the debit notice in a format the customerrequires and sends the message to the customer. The status of thetransformed bill in the consolidator/iCSP is set to paid (step 585). Theconsolidator/iCSP may then send a credit notice to the biller. Theconsolidator/iCSP may generate a credit notice in a format requested bythe biller and send that message together with a status change requestto the BSP (SetEBPPStatusRequest) (step 590). The BSP may change thestate of the bill to “paid” (step 595) and send a credit notice to thebiller (step 598).

[0060]FIG. 6 is a flow diagram of an exemplary inventive billpresentment process consistent with the present invention. The customeror a user logs in at the CSP/iCSP (step 610). The customer or user mayuse standard login procedures such as digital IDs (X.509), SSL, and/orclient authentication. In certain embodiments, the distinguished name(DN) must be authorized for Web access in the master data of theconsolidator/iCSP. The user may then select a client (customer) or, ifthe user has no clients, directly select the consolidated list of bills(GetListOfBills) of the customer for whom he has logged in (step 620).In response, the user may be able to access the following exemplary datarelating to the bills:

[0061] invoice reference, biller name, billers banking account, duedate, amount with currency, business transaction (bill) state (such as“open,” “dunning,” “due,” “scheduled,” “paid,” or “paid with differentamount,”) In certain embodiments, the user may be able to select ahyperlink which will allow the user to access additional informationrelating to the bill (step 630). The hyperlink may redirect the user toa information page of the biller, normally hosted on the BSP. Suchredirection may take place over a secure connection, such as one usingSSL. As an alternative, the page can also be on a web server of thebiller.

[0062] The BSP authenticates the customer (step 635). Authentication maybe performed based on a token that may have been generated at the timethe bill details were prepared and/or passed on as part of the billsummary which is passed back to the BSP together with the hyperlink. Ifthe customer requested strong authentication, the bill may be presentedonly if the authentication matches one of the certificates, which mayhave been specified in the CustomerInfoResponse transmitted from theConsolidator/iCSP to the BSP in step 520 of FIG. 5. The BSP may maintaina number of HTML templates and may select a template based on thereferenced business transaction (bill). The template may indicatebusiness transaction data to be filled in. For example, the bill may bepersonalized with the biller's advertisements or advertisements ofaffiliated third parties. The third party advertisements to add may bechosen, for example, based on the customer information. For example, thecustomer's zip code may be used to select advertisements of thirdparties doing business in the customer's zip code. The generated HTMLpage comprises a hyperlink to the itemized bill. The customer selectsthe hyperlink to the itemized bill (step 645) and receives (afterauthentication) the bill (step 650). The bill may be, for example, inthe PDF format.

[0063]FIG. 7 is a flow diagram of an exemplary process for registering acustomer for an electronic billing (e-billing) process consistent withthe present invention. The customer or a user logs in at the CSP/iCSP(step 710). The customer or user may use standard login procedures suchas digital IDs (X.509), SSL, and/or client authentication. In certainembodiments, the DN must be authorized for Web access in the master dataof the consolidator/iCSP. The user may then select a client (customer)or, if the user has no clients, directly select the consolidated list ofbills (GetListOfBillers) (step 720). The consolidator/iCSP may possessan HTML template containing information of electronic billers. The listmay be completed with logos and biller data from the BSP usinghyperlinks (alternatively the data may be maintained locally on theconsolidator) (step 730). The presented list also contains a customerregistration status at the respective biller (inactive, active,registration_requested, registration refused). The registration statusmay be stored, for example, in a BCR table (Biller Customer Relation) onthe Consolidator.

[0064] The customer selects a biller (step 740). The URL for theregistration form may redirect the customer to the BSP or to a BillerWeb server (step 750). The BSP (or Biller Web server) identifies thecustomer, verifies and completes the customer information (step 760).The BSP may verify the customer and complete the customer informationby, for example, obtaining a customer PID (Partner IdentificationNumber) from the URL. If the customer cannot be authenticated, the BSPmay get customer master data matching the received PID from theConsolidator. A personalized registration form (CustomerInfoRequest) maybe transmitted to the Consolidator/iCSP (step 770).

[0065] A registration form is completed and posted (step 780). Theregistration form may be presented, for example, using biller-specificHTML templates and containing master data of the customer (noteditable). The registration form may comprise buttons to register orcancel the registration. Additionally, other information such as the BCN(Biller's Customer Number or debtor number) may be included. If thecustomer processes the bill in an ERP system, the registration form maybe extended by a field to allow entry of a CBN (Customer's BillerNumber=creditor number). The customer completes the registration formand sends it back to the BSP (step 785). The BSP creates a BCR entry inthe consolidator with, for example, the status “registration_requested”(step 795). The BSP may optionally notify the biller (such as by E-Mail)about the new registration (step 796). The BSP may also send informationto the Consolidator/iCSP (in the form of, for example, aCreateBCRRequest) (step 797) which allows the Consolidator/iCSP tocreate a new BCR (step 798).

[0066]FIG. 8 is a flow diagram of an exemplary process for activating aregistering of a customer by a biller consistent with the presentinvention. The biller or a user logs in at the CSP/iCSP (step 810). Thebiller or user may use standard login procedures such as digital IDs(X.509), SSL, and/or client authentication. In certain embodiments, theDN must be authorized for Web access in the master data of theconsolidator/iCSP. The user may then select a client (biller) and arequest is sent to the BSP (GetBCRList) (step 820). If the user has noclients, the user may define filter criteria for getting a list ofcustomers (step 830). The BSP sends a request onto the consolidator/iCSP(GetBCRList) (step 840). The BSP also processes the consolidator/iCSP'sresponse (step 850) and presents a list of customers to the biller (step830). The biller checks and verifies the customer information onrequested registrations (step 860). For example, a mismatch in the BCNand the customer name should be avoided. If the registration data iscorrect, the biller may send an indication to the BSP to set the BCRstatus to active (step 870). The BSP may then set the BCR state on theconsolidator/iCSP by, for example, transmitting to the consolidator/iCSPa SetBCRState request (step 880). After setting the proper state in theBCR table, the consolidator/iCSP may optionally notify the customer(such as by E-Mail) (step 890).

[0067]FIG. 9 is a block diagram of an exemplary table for mapping theIDs of a biller for a customer to the IDs of a customer for a biller.Methods and systems consistent with the present invention facilitate theintegration of Billers and Customers ERP systems. For example, a BCN(Billers Customer Number) or debtor number may be stored in theconsolidator/iCSP system. This enables the Biller to use existingCustomer identifications in billing data sent to the BSP. Expensivemappings can be reduced or avoided. Based on the information acquired inthe customer registration process, the consolidator/iCSP can map the BCNto a unique Customer identification (e.g. the CPID, Customer PartnerIdentification).

[0068] In another example, the CBN (Customers Biller Number), a creditornumber used in the customer's ERP system to identify the biller, mayalso be stored in the consolidator/iCSP during the customer registrationprocess. This allows the BSP to map a BPID (Biller PartnerIdentification) directly to a Biller ID, known by the Customer ERPsystem during conversion on the BSP. Thus, in certain embodiments, thecustomer would not need to implement difficult and expensive mapping ofIDs.

[0069]FIG. 10 is a block diagram showing integration of e-banking intoan electronic bill presentment and paying system consistent with thepresent invention. E-Banking solutions can integrate bill presentmentusing, for example, a CCX (Consolidator CSP Exchange) interface.Customer may use multiple CSP's (Multi-banking). For example, the CSPcan fetch the current list of bills at the consolidator/iCSP forpresentment, instead of the bills being routed by the CSP. This wouldprovide a customer with the ability to view and pay his bills fromdifferent CSP's (e.g. banks).

[0070]FIGS. 11 and 12 are a flow diagram of an exemplary process forinitiating and performing a bill review by a customer consistent withthe present invention. An employee of the customer, defined here as thedispatcher, may log in at the consolidator/iCSP (step 1105) and selectone or more bills (step 1110). For bills not yet prepared for the reviewworkflow, the dispatcher can select a SetUpReviewWorkflow (step 1115).The dispatcher may be presented with a form that allows the dispatcherto identify one or more reviewers. The dispatcher may identify one ormore reviewers by, for example, entering a list of E-mail address (oraliases). The dispatcher can also enter other information, such asquestions, or assign bill items. In parallel, the dispatcher can havethe itemized bill presented.

[0071] The dispatcher sends the form back to the consolidator/iCSP(PostReviewForm) (step 1120). Based on the information provided, theconsolidator/iCSP may send an E-mail to each of the indicated reviewers(steps 1125,1126). For additional security, the email may be transmittedusing encryption or a private (in-house) network). The email may containa hyperlink (URL) to the work item review bill and a short(customizable) description. Optionally, the email may contain anauthentication token. The status of the business transaction is changedto “bill review”.

[0072] The E-mail receiver (the reviewer) may connect to theconsolidator/iCSP by, for example, the URL listed in the E-mail. Foradditional security, the iCSP may authenticate the reviewer by, forexample, using SSL client authentication (step 1130). The receivedcertificate may, for example, be compared with authorized certificatesin the master data. Alternatively, the consolidator/iCSP may authorizethe user based on a token in the URL or authenticates the user based onanother process, such as a user-id/password mechanism. The customer mayreceive the review form with additional data (steps (1135, 1136) Thereview form may also contains a hyperlink to additional billinformation. The user may add comments and accounting information withrespect to bill contents (step 1140). For example, the user may commentthat certain positions were not received, other positions were ok, orprovide instructions to charge to internal account No. XYZ.

[0073] The completed form is sent back to the consolidator/iCSP(PostReviewForm) (steps 1145, 1146). Other reviewers may process theirworkflow item in a similar way. The dispatcher or any other authorizeduser may access the review form via list of bills at any time. Thesystem sends a message to a predefined address, once all reviewers haveposted the review form and sets the state of the business transaction to“open” or “due” depending on the due date. The reviewers do not need tohave access to any other bills or the list of bills. In certainembodiments, only the authentication/authorization has to be stored inthe consolidator/iCSP. For example, for reviewers with digital IDs, onlythe reviewer's DN has to be stored combined with the right for billreviews.

[0074]FIG. 13 is a block diagram of an exemplary archiving process fordata of billers or customers. As shown in FIG. 13, an archive may bedelivered to the biller or the biller may retrieve an archive (step1305). The archive may be in the form of a CD, DVD ROM, or anotherstorage medium containing a record of the biller's business transactions(bills) with the BSP. An archive may also be delivered to the customeror the customer may receive an archive containing a record of thecustomer's business transactions with the consolidator/iCSP (step 1310).The PSP and a support organization may also receive an archive,containing their own data.

[0075] As shown in FIG. 13, archive 1320 may comprise, for example, anindex. The index may contain, for example, bill summaries of thebusiness transactions in the archive. Archive 1320 may also comprise abusiness transaction report which may contain, for example, a billsummary, a history of all business transaction events, and hyperlinks tothe original messages.

[0076] The index may be digitally signed by, for example, the BSP and/orthe Consolidator/iCSP. Digital signatures help to ascertain that thearchive content has not been altered. Exchanged messages, such as theinvoice, may also be digitally signed.

[0077] Optionally, other cryptographic mechanisms may be applied toavoid any changes of the content of the archive. The archive may bedevilvered to or retrieved periodically, according to the requirementsof the biller or customer. In certain embodiments, the receiver mayconfirm readability of a received archive by sending a messageindicating receipt and acceptance. In certain embodiments, businesstransactions may be removed from the BSP and/or consolidator/iCSP aftercertain conditions have been met, such as receiving all necessaryacceptance messages or after a configurable number of days. In certainembodiments, the archived data should be structured so as to meet therequirements of local state or federal regulations, such as thoserequired for the reimbursement of VAT.

[0078] Modifications and adaptations of the present invention will beapparent to those skilled in the art from consideration of thespecification and practice of the invention disclosed herein. Theforegoing description of an implementation of the invention has beenpresented for purposes of illustration and description. It is notexhaustive and does not limit the invention to the precise formdisclosed. Modifications and variations are possible in light of theabove teachings or may be acquired from the practicing of the invention.For example, the described implementation includes software, but systemsand methods consistent with the present invention may be implemented asa combination of hardware and software or in hardware alone.Additionally, although aspects of the present invention are described asbeing stored in memory, one skilled in the art will appreciate thatthese aspects can also be stored on other types of computer-readablemedia, such as secondary storage devices, for example, hard disks,floppy disks, or CD-ROM; the Internet or other propagation medium; orother forms of RAM or ROM. It is intended that the specification andexamples be considered as exemplary only, with a true scope and spiritof the invention being indicated by the following claims.

[0079] Computer programs based on the written description and flowcharts of this invention are within the skill of an experienceddeveloper. The various programs or program modules can be created usingany of the techniques known to one skilled in the art or can be designedin connection with existing software. For example, programs or programmodules can be designed in or by ® Java, C++, HTML, XML, or HTML withincluded Java applets or in SAP R/3 or ABAP. One or more of such modulescan be integrated in existing e-mail or browser software.

What is claimed is:
 1. A method for processing bills electronically,wherein a bill is created for a customer using billing information andmaster data from a biller and master data from the customer, the methodcomprising the steps of: a) receiving the billing information from thebiller by a first processing module, the first processing module havingaccess to the master data of the biller; b) generating a bill by thefirst processing module using the billing information and the masterdata of the biller; c) requesting data of the customer from a secondprocessing module by the first processing module, the second processingmodule having access to the master data of the customer; d) transformingthe bill into a format specified in the master data of the customer bythe first processing module if the format of the generated bill is notthe format specified in the master data of the customer; e) transferringthe generated or transformed bill to the second processing module by thefirst processing module.
 2. The method of claim 1, further comprising:f) making the transformed bill accessible to a third processing moduleby the second processing module.
 3. The method of claim 2, furthercomprising: g) making the transformed bill accessible to the customer.4. The method of claim 2, further comprising: g) presenting ordelivering the transformed bill to the customer.
 5. The method of claim1, further comprising: digitally signing the generated and/ortransformed bills by the first processing module.
 6. The method of claim1, further comprising: providing the transformed bill with a link to astorage location of the transformed bill or of details of the bill foraccess by the customer.
 7. The method of claim 1, further comprising:sending the generated or transformed bills to a print service.
 8. Themethod of claim 1, further comprising: encrypting the generated ortransformed bills by the first and/or second processing module.
 9. Themethod of claim 1, further comprising: archiving the generated ortransformed bills by the first and/or second processing module.
 10. Themethod of claim 2, further comprising: the third processing moduleproviding means for presenting an overview of the customer's bills. 11.The method of claim 2, further comprising: the third processing moduleproviding means for verification of the generated or transformed bills.12. The method of claim 2 further comprising: the third processingmodule providing means for workflow support or bill dispute.
 13. Themethod of claim 1, further comprising: the second processing moduleproviding means for country specific bill presentation and/or payment.14. The method of claim 1, further comprising: the second processingmodule providing means for exchanging data with one or more furthersecond processing modules.
 15. The method of claim 1, furthercomprising: the second processing module receiving a payment order fromthe customer.
 16. The method of claim 15, wherein the second processingmodule forwarding the payment order or a transformed payment order to apayment service provider.
 17. The method of claim 1, wherein the billinginformation comprises address information of biller, customer, paymentsupplier, payment information, VAT information, itemized billingpositions with relation to purchase order and/or accounting information.18. The method of claim 1, wherein the master data of the billercomprises address information, data format information, information oncommunication addresses, bank and bank account information, userauthentication information, user authorizations information, informationon options for archiving services, options for print services, and/oroptions for notifications.
 19. The method of claim 18, wherein themaster data of the customer comprise address information, data formatinformation, communication addresses, bank and bank account information,user authentication information, user authorizations, information onoptions for archiving services, and/or options for notifications. 20.The method of claim 1, further comprising: the second processing modulehaving means for exchanging data with one or more further firstprocessing modules.
 21. The method of claim 1, further comprising: thesecond processing module having means for exchanging data with one ormore further third processing modules.
 22. The method of claim 1,further comprising: the second or first processing module having meansfor mapping an ID of a biller for a particular customer to an ID of acustomer for a particular biller.
 23. The method of claim 1, furthercomprising: directly transforming the bill from a format used by thebiller into a format as specified in the master data of the customerwithout using an intermediate format.
 24. A computer system forprocessing bills electronically, wherein a bill is created for acustomer using billing information and master data from a biller andmaster data from the customer, the system comprising: memory havingprogram instructions; input means for receiving and entering data;output means for sending and presenting data storage means for storingdata; and at least one processor to execute the program instructions toperform operations comprising: a) receiving the billing information fromthe biller by a first processing module, the first processing modulehaving access to the master data of the biller; b) generating a bill bythe first processing module using the billing information and the masterdata of the biller; c) requesting data of the customer from a secondprocessing module by the first processing module, the second processingmodule having access to the master data of the customer; d) transformingthe bill into a format specified in the master data of the customer bythe first processing module if the format of the generated bill is notthe format specified in the master data of the customer; e) transferringthe generated or transformed bill to the second processing module by thefirst processing module.
 25. The computer system of claim 24, furthercomprising: f) making the transformed bill accessible to a thirdprocessing module by the second processing module.
 26. The computersystem of claim 25, further comprising: g) making the transformed billaccessible to the customer.
 27. The computer system of claim 24, furthercomprising: g) presenting or delivering the transformed bill to thecustomer.
 28. The computer system of claim 24, further comprising:digitally signing the generated or transformed bills by the firstprocessing module.
 29. The computer system of claim 24, furthercomprising: providing the transformed bill with a link to a storagelocation of the transformed bill or of details of the bill for access bythe customer.
 30. The computer system of claim 24, further comprising:sending the generated or transformed bills to a print service.
 31. Thecomputer system of claim 24, further comprising: encrypting thegenerated or transformed bills by the first and/or second processingmodule.
 32. The computer system of claim 24, further comprising:archiving the generated or transformed bills by the first and/or secondprocessing module.
 33. The computer system of claim 25, furthercomprising: the third processing module providing means for presentingan overview of the customer's bills.
 34. The computer system of claim25, further comprising: the third processing module providing means forverification of the generated or transformed bills.
 35. The computersystem of claim 25, further comprising: the third processing moduleproviding means for workflow support or bill dispute.
 36. The computersystem of claim 24, further comprising: the second processing moduleproviding means for country specific bill presentation and/or payment.37. The computer system of claim 24, further comprising: the secondprocessing module providing means for exchanging data with one or morefurther second processing modules.
 38. The computer system of claim 24,further comprising: the second processing module receiving a paymentorder from the customer.
 39. The computer system of claim 38, whereinthe second processing module forwarding the payment order or atransformed payment order to a payment service provider.
 40. Thecomputer system of claim 24, wherein the billing information comprisesaddress information of biller, customer, and/or payment supplier,payment information, VAT information, itemized billing positions withrelation to purchase order, accounting information.
 41. The computersystem of claim 24, wherein the master data of the biller comprisesaddress information, data format information, information oncommunication addresses, bank and bank account information, userauthentication information, user authorizations information, informationon options for archiving services, options for print services, and/oroptions for notifications.
 42. The computer system of claim 24, whereinthe master data of the customer comprises address information, dataformat information, communication addresses, bank and bank accountinformation, user authentication information, user authorizations,information on options for archiving services, and/or options fornotifications.
 43. The computer system of claim 24, further comprising:the second processing module having means for exchanging data with oneor more further first processing modules.
 44. The computer system ofclaim 24, further comprising: the second processing module having meansfor exchanging data with one or more further third processing modules.45. The computer system of claim 24, further comprising: the second orfirst processing module having means for mapping an ID of a biller for aparticular customer to an ID of a customer for a particular biller. 46.The computer system of claim 24, further comprising: directlytransforming the bill from a format used by the biller into a format asspecified in the master data of the customer without using anintermediate format.
 47. A computer-readable medium comprisinginstructions for performing, when executed by a processor, a method forprocessing bills electronically, wherein a bill is created for acustomer using billing information and master data from a biller andmaster data from the customer, the method comprising: a) receiving thebilling information from the biller by a first processing module, thefirst processing module having access to the master data of the biller;b) generating a bill by the first processing module using the billinginformation and the master data of the biller; c) requesting data of thecustomer from a second processing module by the first processing module,the second processing module having access to the master data of thecustomer; d) transforming the bill into a format specified in the masterdata of the customer by the first processing module if the format of thegenerated bill is not the format specified in the master data of thecustomer; and e) transferring the generated or transformed bill to thesecond processing module by the first processing module.
 48. Thecomputer-readable medium of claim 47, further comprising: f) making thetransformed bill accessible to a third processing module by the secondprocessing module.
 49. The computer-readable medium of claim 47, furthercomprising: g) making the transformed bill accessible to the customer.50. The computer-readable medium of claim 47, further comprising: g)presenting or delivering the transformed bill to the customer.
 51. Thecomputer-readable medium of claim 47, further comprising: digitallysigning the generated or transformed bills by the first processingmodule.
 52. The computer-readable medium of claim 47, furthercomprising: providing the transformed bill with a link to a storagelocation of the transformed bill or of details of the bill for access bythe customer.
 53. The computer-readable medium of claim 47, furthercomprising: sending the generated or transformed bills to a printservice.
 54. The computer-readable medium of claim 47, furthercomprising: encrypting the generated or transformed bills by the firstand/or second processing module.
 55. The computer-readable medium ofclaim 47, further comprising: archiving the generated or transformedbills by the first and/or second processing module.
 56. Thecomputer-readable medium of claim 48, further comprising: the thirdprocessing module providing means for presenting an overview of thecustomer's bills.
 57. The computer-readable medium of claim 48, furthercomprising: the third processing module providing means for verificationof the generated or transformed bills.
 58. The computer-readable mediumof claim 48, further comprising: the third processing module providingmeans for workflow support or bill dispute.
 59. The computer-readablemedium of claim 47, further comprising: the second processing moduleproviding means for country specific bill presentation and/or payment.60. The computer-readable medium of claim 47, further comprising: thesecond processing module providing means for exchanging data with one ormore further second processing modules.
 61. The computer-readable mediumof claim 47, further comprising: the second processing module receivinga payment order from the customer.
 62. The computer-readable medium ofclaim 61, wherein the second processing module forwarding the paymentorder or a transformed payment order to a payment service provider. 63.The computer-readable medium of claim 47, wherein the billinginformation comprises address information of biller, customer, and/orpayment supplier, payment information, VAT information, itemized billingpositions with relation to purchase order, and/or accountinginformation.
 64. The computer-readable medium of claim 65, wherein themaster data of the biller comprises address information, data formatinformation, information on communication addresses, bank and bankaccount information, user authentication information, userauthorizations information, information on options for archivingservices, options for print services, and/or options for notifications.65. The computer-readable medium of claim 47, wherein the master data ofthe customer comprises address information, data format information,communication addresses, bank and bank account information, userauthentication information, user authorizations, information on optionsfor archiving services, and/or options for notifications.
 66. Thecomputer-readable medium of claim 47, further comprising: the secondprocessing module having means for exchanging data with one or morefurther first processing modules.
 67. The computer-readable medium ofclaim 47, further comprising: the second processing module having meansfor exchanging data with one or more further third processing modules.68. The computer-readable medium of claim 47, further comprising: thesecond or first processing module having means for mapping an ID of abiller for a particular customer to an ID of a customer for a particularbiller.
 69. The computer-readable medium of claim 47, furthercomprising: directly transforming the bill from a format used by thebiller into a format as specified in the master data of the customerwithout using an intermediate format.
 70. A computer data signalembodied in a carrier wave comprising: code for processing billselectronically, wherein a bill is created for a customer using billinginformation and master data from a biller and master data from thecustomer, the code comprising instructions for: a) receiving the billinginformation from the biller by a first processing module, the firstprocessing module having access to the master data of the biller; b)generating a bill by the first processing module using the billinginformation and the master data of the biller; c) requesting data of thecustomer from a second processing module by the first processing module,the second processing module having access to the master data of thecustomer; d) transforming the bill into a format specified in the masterdata of the customer by the first processing module if the format of thegenerated bill is not the format specified in the master data of thecustomer; and e) transferring the generated or transformed bill to thesecond processing module by the first processing module.